Recently IP-based networks have become increasingly important for delivery of professional content, including video data. Errors in data transmission are generally not acceptable, which makes some sort of FEC scheme necessary.
One issue with FEC systems on IP networks is that channel bit errors can result in packet losses. In addition, buffer and re-routing issues cause burst packet losses. The combination of packet losses from three sources—gross reordering, bit-error induced losses, and burst losses—is preferably low enough so that the FEC scheme is not broken more than the negotiated error rate. Because any bit errors cause the packet to be discarded, there is no requirement for an error correction scheme that can handle errored packets—every packet will either arrive correct or not at all.
As disclosed by the Pro-MPEG Code of Practice #3 release 2 of July, 2004, an RTP payload format for Generic Forward Error Correction Packets has been defined in the RFC 2733 to enable error correction of real time media. This standard allows the use of traditional error correcting codes and can be used with any video format standards (e.g., MPEG, SDI, SDTI, etc.) as long as it is encapsulated in an RTP packet.
To recover burst loss, the same traditional error correcting codes can be applied to non-consecutive media packets that can be spaced among many packets. Each FEC packet is associated to packets periodically selected. Therefore, consecutive RTP packets can be recovered from consecutive FEC packets as shown in FIG. 1.
In FIG. 1, the encoding scheme is schematized for L*D media packets. The period chosen is L. The payload of the kth FEC packet is computed based on the D packets numbered nL+k (0≦n≦D−1). The main advantage of this scheme is the burst error correction capacity. The error correcting function chosen is XOR, which has the ability to recover any one lost packet.
FIG. 2 shows an example of a staggered arrangement for the case of (L=4, D=5). In this example, the FEC packet F1 protects data packets [1, 5, 9, 13, 17], while FEC packet F6 protects data packets [6, 10, 14, 18, 22]. Each FEC packet is transmitted L packet times after the last data packet it pertains to, creating a highly time-linear packet flow on the FEC stream.
The standard requires each individual column-FEC packet to indicate the base sequence number (SN-base), the offset (L) and a number of data packets (NA). Receivers can refer to these transmitted values in each FEC packet to correctly associate the FEC packet with the original data-stream packet group regardless of how the packets are staggered.
Although the Pro-MPEG Code of Practice #3 release 2 of July, 2004 suggests the use of a “staggering” FEC scheme, it does not disclose or suggest how to implement such a scheme. It would therefore be desirable to have a “staggered” FEC scheme that can accommodate varying periods (i.e., L or number of columns) and orders (i.e., D or number of rows). This scheme should stagger the FEC columns in such a way that the resultant FEC packets are as evenly spaced as possible. A scheme such as this would result in minimal end-to-end latency and memory requirements in the receiver as well as provide a more uniform distribution of packets in the transmission channel.